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This document outlines a proposal for the next CM System Software release which for 
the present will be called Release 6. Since it likely that Release 6 will take more than 6 
months to reach the Beta level, a short description of a Release 5 maintenance release 
is included in order to help focus the discussion on options for resource usage and 
timing. This document is also intended to be the basis for discussion for Release 6 and 
therefore is subject to significant changes before the contents for the next release are 
fixed and development starts in earnest. Please note that many of the concepts in the 
proposal were part of the Release X document and hopefully will not be unfamiliar. 


1 Introduction 


There are 3 facets of the CM system software which can change to varying degrees in 
any release, functionality, performance, and structure. Every release affects each of 
these and tradeoffs have to be made to determine where the emphasis and thus the 
resources should be placed. For example, Release 5.0 included major functional exten- 
sions like the Dynamic VP structure, Fortran, and *Lisp types. Performance on new 
applications was improved because of the Dynamic VPs, and additional PARIS func- 
tions. It had very minor structural changes. 


The basic system software structure for Release 5 which evolved from the first CM 
system was designed for interactive, single user, research oriented use primarily in 
Lisp and the Symbolics Lisp machines. While it has been very successful for types of 
users, the structure needs major changes to better support production application use. 
Furthermore, the features supported by the System software structure have increased 
dramatically since it was first designed. And, as was pointed out in the Release X pro- 
posal, it is generally unwise to continually add functionality and increase performance 
without making major changes to the system structure to support the weight of new 
features. Otherwise, the time and effort to make changes, and the support costs will 
start increasing dramatically. Based on the the discussions which led up to the selec- 
tion of the Release 5.0 concepts, it became apparent that the overriding need for that 
release was to add some features to efficiently support scientific computing as soon as 
possible. Therefore, we did not change the software structure in any major way. The 
CM System Software structure now must have major revisions not only because of the 
new features that have been added to the original CM software structure, but also be- 
cause of the very probable shift in emphasis from Lisp and Lisp machines to Fortran, 
C and UNIX front ends (probably SUN4 will have the highest volume.) Currently, 
there are obvious problems with the structure of Release 5.0 on UNIX boxes. For ex- 
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ample, there are Lisp based processes which grow to 60 Mbytes that cause problems 
with swap space and efficiency. In addition, in order to support multiprogramming, 
we will need more close integration with the operating system of the front end. This 
would be quite difficult with the current structure. Therefore, the emphasis for Release 
6 is a major restructuring of the system internals. Since we have about 23 people (in- 
cluding 2 who will soon become AEs) who are trying to develop 3 languages, 
microcode, diagnostics, I/O systems, graphics, simulators, operating system exten- 
sions, and tests and release procedures, we will have be very selective about what new 
features or subsystems we develop. 


The key aspects of the proposed Release 6 are 


1. 


a 


Introduction of the CM Interface - both CMIS and CM Semantics 
Introduction of a CM Operating system that may support multiprogramming 
A new C* compiler which is more supportable and extensible 

Port of the Fortran Compiler to Sun—-4s and some Fortran extensions 
Introduction of New I/O extensions such as *Render. 


An emphasis on tutorial documentation 


The key changes from prior directions are 


a 


Halt Paris Rel-3 development at the Release 5 level (minor extensions like 
integer VP ratios, and some spreads will be part of an interim version of Re- 
lease 5.) 


Halt *Lisp development at the Release 5 level 


Focus on UNIX based machines and probably C as the primary development, 
test, and target front end machines and language. 


NOTE: This implies that Symbolics front ends will 
probably not have the new structure or features intro- 
duced in Release 6. We may want to plan on not sup- 
porting them. 


Start to pick up the continuing development of Fortran from Compass. 
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2 Release 6 Concepts 


In contrast to Release 5.0 which introduced major new features that fundamentally 
changed the usage of the CM-2, Release 6.0 is intended to focus on changing the Sys- 
tem Software structure to increase the CM-2’s performance and utilization. Approxi- 
mately 1/2 of the resources of the CM System Software group will be utilized in revising 
the basic software structure. The remainder will develop a few new features for the 
release, and support the current software. Please note that the support of the current 
software will be accomplished by using a fraction of the time of each developer rather 
than by having a separate support staff. The key aspects of the restructuring include 
the following. 


2.1 CM Interface (CMIS and CM Semantics) 


CM interface has 2 parts which are very important and which need to be fully designed 
and documented, but which will probably only be partially implemented in Release 6. 
They are the Connection Machine Instruction set (CMIS) which defines the instruc- 
tions that make the abstract hardware capabilities of the CM available to compilers 
and some programmers, and the CM exception and event interface (CM Semantics) 
which defines the actions and interfaces of the CM for initialization, I/O handling, 
error conditions, and other non-computational actions such as memory management. 
The CM Interface creates a well defined interface upon which to build the rest of the 
CM System Software. The CM Instruction Set defines a new set of instructions which 
more closely represent inherent hardware capabilities of the machine. CMIS is 
equivalent to the assembly language of most traditional machines. CMIS hopefully 
will reduce the need for new microcoded functions by allowing programmers to get 
access to the high performance parts of the CM-2 without having to write microcode. 
(The CMIS design effort is well underway; there are designs for the framework sup- 
porting CMIS, called IMPS, and a subset of the CMIS instructions.) 


The CM Semantics are the other major part (possibly more difficult to understand and 
define than CMIS) of the CM Interface; they define the CM equivalent to the initializa- 
tion, event, interrupt, and I/O hardware/software interfaces of traditional computers. 
In order to support production applications, the system needs to be more robust and 
predictable. The current error, cold-boot, and hardware systems are not as integrated 
or as well-layered as they need to be. In addition, they were designed for Lisp Ma- 
chines and adapted for UNIX. The CM Semantics will be part of a redesign of these 
systems (the other part will be the CM Operating System, CMOS) which will be tar- 
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geted for more traditional front end operating systems and which will hopefully better 
layered and more extensible. 


The CM interface project is fundamental to the success of this and future releases. It 
requires a significant design and implementation effort. It is clear that the design must 
be complete and solid before the formal implementation begins. In addition, many 
parts of the interface must be implemented for Release 6 to have any significance. This 
is difficult because many of the implementation resources could be diverted to other 
more immediate needs. The following outlines my recommendations for what should 
be done for the CM Interface in Release 6, and what should be done to satisfy the 
conflicting, more immediate needs. 


It is probable that most of the microcode developers (3 now, hopefully we can hire at 
least 2 more for the implementation phase) along with a few others who have other 
experiences will be involved in the design of this project. The design of CMIS should be 
and the design of the CM semantics must be completed before implementation begins. 
Since the CM Semantics are needed by the CMOS, those projects must work very 
closely together. The selection of what CM Semantics need to be implemented is 
greatly dependent upon what features the CMOS will support in Release 6. However, it 
seems Clear that the semantics for initialization, error handling, simple memory man- 
agement, CMIS block downloading and execution, I/O control, simple process switch- 
ing, and debugging need to be implemented. The amount of support multiprogram- 
ming needs to be determined. Most of CMIS should be implemented for Release 6, 
However, it is unlikely that most of existing Paris will be rewritten in CMIS for this 
Release; new Paris functions will be written in CMIS. 


There are 2 major hardware extensions, larger memories and 64 bit floating point 
chips, and one performance improving concept, slicewise data format which need the 
same development resources as the CM interface project. The logical way to introduce 
these would be through CMIS; the more of these that we choose to ship before Release 
6, the less of the CM Interface will be implemented or the later the Release will be. 
Based upon the magnitude of the effort, my guess at the priority for the item, the state 
of the design for an item, and the probable impact on Release 6, I recommend that 


1. Larger memory support be part of a Release 5 maintenance release. 


2. Slicewise data format and 64 bit floating point hardware support be intro- 
duced with Release 6. 


The mechanisms to support the larger memories have a preliminary implementation; 
they have not been tested; about 2 staff months of a PARIS or CMIS developer’s time 
is needed. The 64 bit floating point chip integration is a larger problem since the 
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microcode must be redesigned and implemented. To get only the current PARIS func- 
tions running will take between 6 and 12 staff months of a PARIS or CMIS developer's 
time. We have not yet designed how the SLICEWISE data format fits into Paris. How- 
ever, it will be a minimum of 3 months, probably more. Therefore, it seems unwise to 
implement of 64 bit floating point and Slicewise data both with and without CMIS as a 
base; they probably should be done once with CMIS for Release 6. 


Finally, there are some Paris extensions which need to be done as part of the Release 5 
maintenance release. Unfortunately, they draw from the same limited pool of 
microcoders. The functions are integer VP ratios, interning of geometries and VP sets 
(for Fortran), convolution, and new Spread Paris functions. While it would be best to 
defer these, it seems that they must be done before Release 6. 


2.2 Connection Machine Operating System (CMOS) 


There are a number of software subsystems in the current system that could loosely be 
called the CM Operating System (CMOS). They include the error system, the hard- 
ware system, the coldboot and attach system, and, on the UNIX front ends, the CM 
daemon. They need major redesigning and restructuring just to support our current 
software; they need to be redesigned to support CM multiprogramming (aka timeshar- 
ing). This key project which is closely related to and depends upon the CM Semantics 
part of the CM Interface will design a CM operating system and will implement key 
parts of it for Release 6. (Please note that unlike developing a new OS for new hard- 
ware, this project is more limited in scope since it integrates with an existing front end 
OS.) Some of the goals that this project has are 


1. create a unified model for allocating CM resources including CM ports, and 
V/O devices, and, for multiprogramming, memory and processing time. This 
probably includes clearly defining what a CM process is and how it relates to 
the front end process. 


2. create a unified model for initializing the system, and for handling, reporting, 
and recovering from system and user errors. 


3. Redesign and develop the portions of the CM OS currently encompassed by 
the error, hardware, and coldboot systems to more effectively support the 
UNIX front ends. 


4. Design and start development of the parts of the CM OS that are needed for 
multiprogramming. 
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One very important aspect of this project is that the current OS-like subsystems were 
designed to run on Symbolics Lisp machines. This has been a constant problem for the 
VAX and now the Sun systems since the philosophy of embedding everything into the 
Lisp world is not consistent with the model supported by UNIX, in particular, and 
most operating systems in general. For example, there is a very large daemon process 
which performs functions like downloading microcode, fingering users, and attaching. 
This process takes a good deal of virtual memory space. It could be replaced by a sim- 
pler, smaller process which is invoked only to initialize the system and which then goes 
away, a driver, and a library of other functions. Similarly, the current error system pro- 
duces a voluminous amount of data and very little information for the typical user; it 
needs to be redesigned to return meaningful information to both users and to proc- 
esses. The current error system is inadequate now and becomes even more so for a 
multiprogrammed environment. For example, the error system does not make any dis- 
tinctions between actual hardware failures, and program errors which violate some 
hardware enforced boundaries. For production applications this is unacceptable. 


This is a critical project for the long term success of our system. It must be fully de- 
signed for this release and major parts of it need to be implemented to make the re- 
lease a success. The replacements for the current OS-like systems and the CM daemon 
must be implemented. Even this is very ambitious considering our current lack of peo- 
ple experienced in OS design and development. Full support for multiprogramming 
seems to be even a more ambitious goal in light of the fact that we have not defined the 
basics of a CM process. However, every attempt will be made to get the basics of multi- 
programming support in the release. 


The major resource conflicts with this project are the VMEIO project, and the release 
and support of the UNIX systems, particularly the release of the Sun system. However, 
these obviously must be done and available before Release 6 is shipped; they will be 
part of a maintenance version of Release 5.0. 
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2.3 C* Language and Compiler 


The current C* compiler is essentially unsupportable. It must be replaced as soon as 
possible with a design which is built for production use and extensibility. In order to 
get a working compiler which is faster and which produces more efficient code avail- 
able as soon as possible, the language must be reviewed and probably subsetted in 
some aspects and extended in others in order to support some key CM functions like 
SCAN. Beside redesigning the compiler and modifying the language, the C* project 
will incorporate the Dynamic VP system introduced in Release 5.0, and replace the 
2-D grid package with a more integrated approach which supports N-D structures. 
However, it is clear that this project will focus on building a more supportable, extensi- 
ble system which compiles faster and which produces more efficient code. 


Secondary goal are that this project also be the focal point for investigating language 
interoperability, particularly for Fortran and C*, and for developing a common com- 
piler backend. Hopefully, this work can be used to help make all the languages more 
easily retargetable to new front ends. 


For Release 6, C* will have a new compiler and will better support many of the most 
important CM programming idioms. It is unlikely that many optimizations will be in- 
cluded in the release. The major resource conflict for C* is supporting the current 
compiler. However, since no extensions are planned for C* until the compiler is deliv- 
ered, it is realistic to assume that a new C* compiler will be delivered as part of Release 
6. 


2.4 Diagnostics 


The diagnostics that we have today are greatly improved from anything that we have 
had in the past. However, they were designed to run well on Lispms; they also need a 
restructuring and increased coverage. Currently, many of the diagnostics are car- 
ryovers from when the CM was being debugged, and do not follow a consistent set of 
conventions. Therefore, there are many places where errors are not reported and 
where extensions to support new hardware or increased coverage is nearly impossible. 
In addition, the diagnostics are not easily partitioned to support the differing needs of 
engineering, manufacturing, and customer support. By restructuring the diagnostics, 
we will create a system that will make it possible to have the speed required by CSG, 
the isolation capability needed by manufacturing, and the debugging capability 
needed by engineering. Finally, there remains many holes in the coverage of the cur- 
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rent diagnostics; they must be eliminated if we want to make manufacturing and cus- 
tomer support more efficient. 


In addition to the restructuring and coverage increase, there are a number of projects 
which will require additional diagnostics. They include the VMEIO board, Datavault 
extensions, larger CM memories, 64 bit Weitek chip diagnostics, and diagnostics tai- 
lored for the small machine. Based on the current staff level of 4 people, the restructur- 
ing will be designed and implemented for key, but not all, parts of the system. However, 
we should be able to support the new hardware in diagnostics. 


2.5 Fortran 


The CMF compiler needs a number of significant extensions. These include 
1. Compiler Directives 
Use of the Dynamic VP system 


Port to the SUN 4 


a 


Data Motion optimizations 
Automatic Parallelization of existing Fortran programs 
6. Interoperability with other languages. 


The first 2 will probably be done by COMPASS concurrently with Release 6. However, 
it appears that this along with full Fortran 77 compatability will delay the final release 
of the compiler until June 1989. In the interim, we will receive additional, more fea- 
tured versions of the compiler. The first interim release would be in December and 
would contain support for many directives, dynamic VPs, and geometries. In order to 
get the design and development work done, Compass needs constant support from us. 
First, we will need to support them with information on the intent and design of the 
syntax for the directives. Then we will have to write tests and support them with test 
programs during the development phase. Therefore, at least 2 people (hopefully 3) will 
be completely utilized for the remainder of the COMPASS development project. 
Based on the probable schedule for Release 6, the Fortran Compiler with directives 
and the dynamic VP system will probably run on the maintenance release 5; it will use 
Paris as a target while Compass is doing the primary development. This compiler will 
run with Release 6 about 1 to 2 months after Release 6 is available. 
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The SUN4 port is an important project which we should do as soon as possible. In 
addition to the facts that COMPASS has no RISC experience and apparently no staff 
to do the job in the next 6 months, I believe that TMC needs and wants to do this task to 
start taking over the continuing Fortran compiler developments in order to reduce our 
dependence on COMPASS. Finally, I believe that we want to create a somewhat more 
portable approach for the compiler since we are likely to have more front ends. There- 
fore, since the Sun4 and the most likely new front ends use RISC processors, and since 
the best compilers on those processors are usually the C compiler, we probably will 
choose an approach that will produce C with Paris as an intermediate representation. 
This would then be compiled by the native compiler for the front end. This approach 
has advantages and disadvantages. The major advantage is that the intermediate rep- 
resentation could be made to be compatible with C* and thus some technology could 
be shared. The major disadvantage is that additional development will be needed to 
make source language debugging effective. This project will probably not start in ear- 
nest until November since we have to get the directives project design completed be- 
fore we can assign someone to it. After that it will probably take at least 3 to 4 months 
of work to get a Beta level version available with about 3 people on the project. Under 
the assumption that we can get those resources, Fortran would be first available on a 
Sun4 on a version of Release 5; another version would follow on Release 6. 


The Data Motion optimizations are very important for the long term success of the 
CM and Fortran since they will reduce the burden of the programmer to hand opti- 
mize his/her programs. While the directives do create a burden for most programmers, 
they will probably be sufficient to allow us to defer Data Motion optimizations for 
Release 6. The magnitude of the effort is fairly significant and again I feel that while 
COMPASS could do this in the future that this is an important project for TMC to do 
in order to improve our compiler expertise. In any case it will not be part of Release 6. 


Automatic Parallelization of existing Fortran programs (dusty decks) has been men- 
tioned as something that we may want to consider. COMPASS has an embedded vec- 
torizer/parallelizer which they are interested in adapting to the CM. If we are inter- 
ested in this, we need to start negotiating now. However, this would take additional 
TMC resources and would not start with Release 6. 
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2.6 1I/O System Development 


While there are a number of ongoing I/O device developments, the most critical items 
are to determine how our I/O subsystems integrate with the CMOS, and CM Interface, 
and how out I/O system supports data intensive, production applications. The first 
item is part of the base level projects, but may have some effective on the current I/O 
software. The second item is much more nebulous and difficult. 


The Datavault needs the following projects to be done. 
1. Multiple DataVaults on an I/O bus 
2. Multiple DataVault file striping 
3. Independent disk mode 
4. NFS accessible Datavaults 
5. An effective back up system. 


In addition to these, there will be nearly continuous DV software development in sup- 
port of additional hardware features. For example, the hardware will have an excep- 
tion system which will have to be reflected in the software. Another example is the use 
of the command channel instead of the ethernet for commands. Software support for 
these and other likely hardware additions will require 3 to 4 staff months; the changes 
will be part of the Release 5 maintenance release if the hardware can support them. 
The first item, multiple DVs on an I/O bus will take 1 to 2 staff months; the second will 
take 2 to 4 staff months. The independent disk mode has not be fully designed; how- 
ever, it seems that a very simple pseudo-independent mode can be designed and im- 
plemented in 1 to 2 months. The NFS accessible DV is a relatively complex project that 
has implications about security; it would take between 4 and 6 staff months. There- 
fore, based on the current DV development resources of a fraction of one manager, 
and one engineer, Release 6 will contain support for Multiple Datavaults on an I/O 
bus, and File striping. The other projects will be part of a future release. 


The Framebuffer needs some higher level software to aid in scientific visualization. 
The current interface is too low level. A start is to develop *Render in order to allow 
users to manipulate image rather than bits and parts of an image. *Render would also 
be integrated with the languages. There are 2 phases to this development; first Essen- 
tial *Render would be developed and would take between 2 and 4 staff months, and 
then full *Render would follow and would take an additional 4 to 6 staff months. In 
addition, some time must be reserved for creating demos and for developing a plan for 
the incorporation of standards and for determining what other tools are needed for 
scientific visualization on the CM. For Release 6 based on the current resources of 2 
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people who are doing graphics work, we should be able to develop *Render and to 
create some interesting demos for Release 6. 


The VMEIO system project is necessary to create a high performance interface to 
other systems. Since it is needed relatively soon, it will be part of the Release 5 mainte- 
nance release. It has been underway since about July 1, 1988. About another month of 
both system development and diagnostic development are required. After that there is 
between and 2 and 4 staff months are needed to integrate this with the datavault and to 
work with Convex. Unfortunately, this project conflicts with the CMOS and datavault 
resources. 


2.7 SQA and Release Procedures 


In order to improve the quality and timeliness of our releases, we need more system 
level tests and more automated release and installation procedures. While the subsys- 
tem designers and developers are and will continue to be responsible for developing 
unit tests, system tests and test frames are needed to insure that what we release works 
as advertised and does not break something that worked before; these should be devel- 
oped by qualified software developers who are not attached to a subsystem develop- 
ment project and whose focus is quality and consistency as opposed to features. At this 
time we have only the most rudimentary tests. As we add more features and more sub- 
systems, system testing becomes increasingly important. In addition, we need more 
efficient release and installation procedures. Our current procedures are inadequate 
and manpower intensive. With the new software structure, we need to create new and 
better ways to update the installations without having to change the whole system. De- 
veloping the needed software manufacturing tools is again a significant development 
project that will result in no new features but in a more robust system which can be 
released and installed much more efficiently. Since Release 6 is intended to focus on 
building a system which is more robust and extensible and be focused on UNIX front 
ends, it is the appropriate time to make the changes needed. This SQA structure and 
Software Manufacturing tools project is critical to the development, deployment and 
success of Release 6. Without it, the release would be greatly devalued. Therefore, at 2 
and possibly 3 people will be assigned to this project. 


2.8 *Lisp developments 


While *Lisp will be supported and some additions completed, there will be no new 
*Lisp developments. 
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2.9 Documentation Development: 


Our documentation reflects the hectic pace of new feature development and the pau- 
city of writers; most documents need major revisions and many additional ones are 
needed. Release 6 is the opportunity to start on this since the number of new features 
and subsystems are small. Therefore the writers can concentrate on improving the 
quality and scope of our documentation rather than on documenting new features. The 
documents that are needed include 


1. Rewrite of *Lisp Reference manual, and a *Lisp Users guide and Tutorial 


2. Completion of the C* Reference Manual, updating of the C* Users Guide, and 
a new C* Tutorial. 


3. Recasting of the Fortran Reference manual (from Compass), updated Fortran 
User’s Guide, and a Fortran Tutorial 


4. Updating of the DataVault User’s Guide 

5. Rewrite of the Framebuffer User’s Guide 

6. Creation of a *Render reference manual 

7. Creation of a CMIS reference manual, and CMIS user’s guide 
8. Creation CM applications programmers guide (New) 

9. Creation of a CM-2 principle’s of operation 


From the recent comments, more tutorial type documentation is needed. In order to 
do that, we need to refocus our experienced writers to develop them while bringing 
newer people in to develop the reference and user guides. 


In addition, it has been hypothesized that the small machine will require on-line docu- 
mentation if it is going to reach its goal of having productive users in 90 days. This is a 
major documentation development task. 


It has been estimated by Janet and Guy that we need close to 2000 pages of documenta- 
tion and that a productive writer can produce about 100 pages of good documentation 
per year; thus, if we assume that we are twice as productive, we probably have at least 
10 staff years of documentation work to do. Since we have 2 3/4 writers and 1 contract 
writer (for Fortran), we probably can not complete all the documentation required in 
the Release 6 timeframe even if we hire more staff immediately. In order to make the 
new structure of the system useful, we must first do the basic documentation for the 
new subsystems, the new features in the languages, and release notes. Thus, we prob- 
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ably will be able to maintain the current documentation, create the *Render and CMIS 
reference manuals, and update the C* and Fortran language reference manuals. In 
addition, it seems that the most critical documentation projects are C* and Fortran 
tutorials. At least one of these should be able to be started with the current staff; addi- 
tional staff is needed for both. Finally, I believe that the most critical document for new 
users is the CM Application Programmers Guide; this is a major, long term develop- 
ment. While this may be started during this period, it is unlikely that it will be pub- 
lished during the Release 6 timeframe. 


2.10 Simulators 


The current Paris simulator which is used to run CMF and C* on simulators is written 
in Lisp and is thus big, and slow on Unix front ends. It is also expensive to put on 
multiple machines since it requires a Lucid Lisp license. The Paris simulator should 
probably be rewritten to be targeted for Unix front ends, smaller, faster, low cost, and 
readily portable to many front ends. In addition, CMIS will need a simulator; it also 
should be targeted to run well on Unix boxes and to be readily portable. Finally, the 
*Lisp simulator will be compatible with *Lisp; it should be available shortly after the 
initial shipment of Release 5.0. 


While there has been some speculation about the size of the effort to write a new Paris 
simulator, there has been no real design time expended and it is an all or nothing pro- 
ject. Furthermore, it may be wise to consider implementing the Paris simulator on top 
of the CMIS simulator which has no even been discussed. However, a design team will 
be designated and determine the general approach and create some estimates. In or- 
der to help that design team some input is needed about how simulators fit in our mar- 
keting and sales plans. For example, if the simulators will only be delivered with CM 
hardware installations, then the amount and intensity of the development effort will _ 
probably be greatly different than if we choose to generally distribute simulators. 


2.11 Application Libraries 


While the first application library, CMSSL, is being design and developed by NCG, it 
is an important part of the overall CM System Software plan. At this time the length of 
the development phase is unknown. However, two items seem relatively important to 
help insure that CMSSL integrates well with the base system software. First, it should 
be designed to run well of UNIX front ends. Second, the low level kernels should be 
written in CMIS. Otherwise, some parts of CMSSL will have to be rewritten to run on 
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the Release 6. If it is possible CMSSL should be part of Release 6 and not of Release 5. 
While this may cause some delay while the design and initial development of the re- 
lease begins, the result will be a better more integrated product. In the interim, the 
higher level code can be written and tested on Release 5. 


It also seems that some focus on developing a Data Management system is needed if 
we want to exploit some markets. While this is unlikely to start for some time, some 
discussions should take place as early as possible to help insure that Release 6 has the 
proper structure to support Data Management applications and tools. 
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3 Preliminary Schedules 


Release 6 contains such radical changes to the basic system structure that an intensive 
design period is required. Part of that design phase will include synthesizing the actual 
development schedules. However, for planning purposes the Release 6.0 schedules fol- 
low. 


1. Analysis and Design - 2 Months (September, October, 1988) 

2. Development and Unit Testing - 5 months ( Nov, Dec, 1988, Jan-March, 1989) 
3. Alpha Testing - 1 month (April, 1989) 

4. Beta Testing - 2 Months (May, June 1989) 


5. Customer Shipment of Release 6.0 - 10 months after development start (July, 
1989). 


The one major conflict with this schedule is that a maintenance release for Release 5 
will be required. It probably should be planned 4 to 5 months from the first customer 
shipment of Release 5.0. Therefore, the Release 5.1 schedule under the assumption 
that very little new functionality is added to the release follows. 


1. Bug Fixing and Limited development - 3 months (Sept-Nov, 1988) 
Alpha Testing - 1 month (Dec 1988) 
Beta Testing - 1 month (Jan 1989) 


i a 


Customer Shipment of Maintenance Release 5.1 - February 1989. 
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Appendix A. Release 6 Features 


Base System Software 
VAX and Sun4 Front Ends 
Symbolics Lisp Machines will not be supported 
CMIS - all basic functions 
CM Semantics 
Initialization 
I/O events 
Error Conditions/Actions 
Software Caused 
Hardware Caused 
CMIS/IMP downloading, switching, execution 
Debugging control 
Memory Management Interface 
Process Control Interface 
CMOS - probably not multiprogramming 
Replacement of all low level OS-like functions in Release 5.1 
Paris - Same as Release 5.1 
64 bit Floating Point 
(Possible)Complex Numbers 
(Possible) Slicewise Data 
No Other new functions 


Languages 
C* - New compiler 
NEWS 
Scans/Spreads 


Faster Compiler Time 

More Supportable 

Better Generated Code 

(possible) Interoperable with CMF 

Limited or no significant Optimizations 
Fortran - Probably the Complete Compass Compiler 

Full Fortran 77 support 

Directives 

FORALL statement 

In processor Arrays 

More Runtime Checking 

Sun4 Support 
*Lisp - Same as Release 5.1 
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Application Libraries 
CMSSL 


Simulators 
*Lisp (same as Release 5.1) 
Paris (may be rewritten) 
CMIS 


Diagnostics 
Restructured to Run Well on UNIX front ends 
Test Subsetting for CSG purposes 
Better Coverage 


1/O 
Datavault 
Multiple DVs on an I/O Bus 
Multiple DV Striping 
(Possible) Simple Independent Disk Mode 
Graphics 
*Render 
VMEIO - Same as Release 5.1 


SQA/Release Procedures 
System Test Frame 
Consistent Test Interface 
Report Interface 
Automated Distribution System 


Documentation 
CMIS Reference manual 
*Render Reference Manual 
C* Tutorial 
Fortran Tutorial 
(Possible) Application Designers Guide 
(Not Likely) OnLine Documentation 


eS See 
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Appendix B. - Release 5.1 Features 


Base Software 
Small Machine Support 
Support For Sun4, VAX, and Symbolics Lisp Machines 
Integer VP Ratios 
VP/Geometry Interning 
Support for Larger Memories 
Simple microcode loader 
Paris the same as Release 5.0 
No 64 bit floating Point 
No Slicewise Data 
No Complex Numbers 


Languages 
C* - Same as Release 5.0 
Fortran 
Most Directives 
Dynamic VP Support 
(Not Likely) Sun4 Support 
*Lisp — Same as Release 5.0 


Application Libraries - none 
Simulators - Same as release 5.0 
Diagnostics — Same as release 5.0 


1/O 
Datavault - Same as Release 5.0 
Graphics 
(possible) Essential *Render 
VMEIO Support 


SQA/Release Procedures - Same as Release 5.0 


Documentation — Same as Release 5.0 
Release Notes 


eS SS EE 
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